The present invention is related both to computer processor architectures and to a layer of software, called a virtual machine monitor that abstracts a computer processor to provide a virtual machine interface to one or more operating systems. Therefore, a brief overview of computer systems, processors, and virtual machine monitors is provided in this subsection.
FIG. 1 shows a high level overview of the core processing components of a computer system. The core components include a processor 102, one or more memories 104, and a system bus 106 interconnecting the processor 102, memory 104, and a bus bridge 108 that interconnects the system bus 106 with a second-level bus 110. The second-level bus 110 is, in turn, interconnected, via bus bridges 112-113, with I/O busses 114-115, respectively. Various controllers 116-121, including communications controllers, mass-storage-device controllers, video-display controllers, and other such controllers, are connected to the processor 102 and memory 104 via the I/O busses 114 and 115, bus bridges 112-113, secondary-level bus 110, bus bridge 108, and the system bus 106. Many modern computer systems feature multiple processors, multiple, tiered memories, and a large number of additional components and busses. Data flows into the computer system via communications ports, including input devices, mass-storage devices, and other such data sources connected to controllers 116-121, and data flows out from the computer system from memory 104 to various output devices, including communications ports, mass-storage devices, video displays, and other such devices through the various controllers 116-121.
FIG. 2 illustrates the overall function of a computer processor. It should be noted that FIG. 2 is a vast simplification of the many interrelated functional units within a modern processor, but most of this complexity is not relevant to the current invention, and therefore neither illustrated nor discussed. The processor 200 includes a number of general registers 202, a number of control registers 204, and one or more processor status registers (“PSRs”) 206. These registers are essentially small units of extremely high-speed memory integrated with the various execution and control components within the processor. The heart of the processor, in many ways, is a group of components collectively referred to, in FIG. 2, as the instruction-execution engine 208. The instruction-execution engine 208 interfaces to a collection of components referred to, in FIG. 2, as the system-bus interface and memory-access-for-read component 210 which allows the instruction-execution engine 208 to read data and instructions from memory via the system bus. The instruction-execution engine executes instructions retrieved from memory, using the general registers 202 for storing and retrieving temporary results from instruction execution. In the course of executing instructions, the instruction-execution engine may output data to a system-bus interface and memory-access-for-write component 212. Thus, a processor, at a highest level of description, is essentially an instruction-execution engine that reads instructions and data from memory and that writes data and instructions to memory.
The instruction-execution engine is controlled, in various ways, by the contents of the control registers 204 and status registers 206. In addition, a processor may receive various inputs in addition to instructions and data sets from memory, including interruption signals and data retrieved from registers within controllers and other external devices. Similarly, a processor may generate interruption signals and other such signals, and may write data to registers within controllers and other external devices. For the most part, processor function is controlled by instructions fetched from memory and executed by the instruction-execution engine. In addition, built-in logic within the processor may execute complex functionality that supports the instruction-execution engine and that responds to various external signals and internal conditions.
FIG. 3 shows the overall organization of logic within a computer system. At the lowest, most fundamental level 302 are the hardware/firmware components of the computer system, including those components shown in FIG. 1 and various peripheral and additional logic-containing devices. The hardware/firmware level is the least abstract, physical, logic layer. However, a modem computer system containing only a hardware/firmware physical logic layer is almost completely useless. The hardware/firmware layer supports instruction execution and component intercommunication, as described above, but, by itself, has no way of acquiring instructions to execute. The next highest logic layer in FIG. 1 is commonly referred to as the “operating system” 304. Operating systems were first developed as relatively simple collections of assembler-language routines for facilitating largely tediously manual operation of stand-alone, one-task-at-a-time computers. As the complexity of computer systems has increased over time, and the variety and number of internal and external components interconnected within and to computer systems have grown, computer operating systems have become correspondingly much larger and far more complex. Even operating systems for relatively simple personal computers now routinely comprise many megabytes of computer instructions. Operating systems provide a huge number of routines for interconnecting and controlling the various components of a computer system, and provide interfaces both to application software programs as well as to human users.
A computer system comprising the hardware/firmware logic layer 302 and an installed, booted, and properly functioning operating system 304 provides to a user an input environment through which the user can input various commands and receive responses to those commands from the operating system. However, the set of commands provided by an operating system are rather limited in scope and functionality. The complex, useful functionality provided by modern computers is generally implemented in application programs that run within the application-program-execution environment provided by the hardware/firmware logic layer 302 combined with the operating system 304. In FIG. 3, various application programs, such as application program 306, are shown at the highest logic layer within the computer system. Application programs include word-processing programs, games, database-management systems, spreadsheets, email applications, compilers, and high-level programming and development environments.
Many different operating systems are currently commercially available. Some operating systems, such as the Microsoft XP® operating system, can be run on a variety of different hardware platforms. Initially, operating systems were ported, by extensive modification, to each different hardware platform on which they ran. A more modem approach is to create a variety of different logic levels within an operating system, and to isolate hardware-platform dependencies within a hardware-dependent layer within the operating system. By designing operating systems in this fashion, only the relatively small, hardware-dependent layer needs to be modified when porting the operating system to a different hardware/firmware logic layer.
In addition to facilitating operating-system hardware independence, the concept of a hardware-dependent layer has led to a more general virtual-machine-monitor layer. FIG. 4 illustrates logical layers within a computer system employing a virtual-machine monitor. As can be seen by comparing FIG. 4 to FIG. 3, the virtual-machine-monitor layer 402 is interposed between the hardware/firmware logic layer 404 and an operating-system logic layer 406. However, unlike the single-operating-system computer illustrated in FIG. 3, the virtual machine monitor 402 can support multiple, concurrently functioning operating systems, referred to as “guest operating systems.” The virtual machine monitor is a rather thin layer, with respect to functionality, with the guest operating systems providing the bulk of functionality traditionally supplied by an operating system directly layered above the hardware/firmware logic level. Each guest operating system, such as guest operating system 408, can generally support concurrent execution of multiple application programs, such as application programs 410-413 running within the application-execution environment provided by guest operating system 408.
The virtual machine monitor approach provides many advantages. For example, allowing concurrent execution of multiple operating systems allows a computer system to concurrently execute various operating-system-specific application programs, without needing to port application programs designed to execute within the application-program-execution environment provided by one operating system to the application-program-execution environment provided by another operating system. Different operating systems may have different sets of advantages and disadvantages, and by concurrently running multiple operating systems, a user may selectively employ specific operating systems that offer the greatest advantages and least disadvantages for particular tasks. A virtual machine monitor can be designed to provide many different machine interfaces through operating systems, so that, for example, an operating system can be tested and debugged on a computer system with a virtual machine monitor simulating a particular hardware/firmware interface prior to development of that hardware/firmware interface. When the hardware/firmware interface becomes available, the operating system can be immediately used on the newly available hardware/firmware interface, rather than becoming available only after a lengthy testing and debugging process.
There are many different approaches to creating virtual machine monitors. At one extreme, the virtual machine monitor would offer a defined, standard interface to all guest operating systems, and the guest operating systems would be developed to conform to this interface. However, the more common approach, and rather opposite approach, is for a virtual machine monitor to simulate or emulate the hardware/firmware platform interface to which a guest operating system was originally developed. Because the virtual machine monitor is generally a much smaller and simpler program, it is easier to modify the virtual machine monitor than to modify guest operating systems or require the guest operating systems be rewritten to a standard virtual machine monitor interface.
In general, virtual machine monitors provide a guest operating system with the illusion that the guest operating system is executing correctly on top of a hardware/firmware interface, and the guest operating system is generally unaware of, and completely isolated from, the other guest operating systems concurrently supported by the virtual machine monitor. In order to accomplish this, the virtual machine monitor employs many different features of the hardware/firmware layer designed for direct support of operating systems, rather than virtual machine monitors. In many cases, employment of these features by the virtual machine monitor introduces instruction-execution overhead, increased instruction-execution latencies, and other such effects that, in the aggregate, result in decreasing the performance of guest operating systems with respect to the performance that the guest operating system could achieve running directly on top of the hardware/firmware interface. In certain cases, the performance degradation is unavoidable. If two or more guest operating systems are concurrently operating, the resources provided by the hardware/firmware layer must necessarily be shared between them, with the result that each guest operating system is provided a portion of the machine resources, rather than all of the machine resources, over relatively long time periods. However, other performance degradations arise from the virtual machine monitor using hardware/firmware features that are intended for direct operating system usage. Designers, manufacturers, and users of computer systems employing virtual machine monitors have therefore recognized the need for identifying and eliminating certain types of performance degradation that result from interposing a virtual machine monitor between the hardware/firmware logic layer and guest operations systems.